|
Corporations have made massive investments in mainframe-based applications. Despite industry hype to the contrary, most corporations continue to add mainframe computing capacity and are developing new mainframe-based applications. IBM estimates that approximately 50,000 mainframes currently run SNA’s Virtual Telecommunications Access Method (VTAM) software and function, therefore, as SNA hosts.
The primary networking protocol used by mainframe computers is IBM’s Systems Network Architecture (SNA). SNA was first introduced in 1974 and it has evolved continuously to support emerging networking technologies. Legacy SNA networks are centrally controlled and provide highly controlled levels of performance and reliability.
The original, hierarchical style of SNA networking, called subarea SNA, is still widely used to support large-scale, mission-critical applications, such as credit card authorization systems, automatic teller machine networks, and airline reservation systems.
When other types of applications, such as client-server applications, began to emerge, IBM developed a new decentralized type of SNA networking called Advanced Peer-to-Peer Networking (APPN). This tutorial focuses on subarea SNA networking.
Legacy SNA networks are structured hierarchically with mainframes at the top of the hierarchy. The following diagram shows the structure of a simple SNA network.
IBM’s mainframe-based VTAM software controls the operation of SNA networks and provides the interface between mainframe-based applications and the network. SNA networks must include at least one VTAM host.
The backbone of SNA networks is made up of interconnected communications controllers. Communications controllers are dedicated networking processors that run IBM’s Network Control Program (NCP) software. These controllers are the SNA routers that make up the campus and wide area backbones of SNA networks.
Peripheral Nodes are the end user systems in SNA networks. As their name implies, Peripheral Nodes exist at the edges of SNA networks. Their sole purpose is to provide users with access to the SNA network, they do not perform any intermediate routing and support only local management functions. End users can be either human users or application programs. Most Peripheral Nodes only allow their end users to communicate with applications residing on a VTAM host. Some Peripheral Nodes also support peer-to-peer communications with users on other Peripheral Nodes.
The protocols and services defined by SNA are described by a 7-layer functional model. This model is similar in scope to the OSI Reference Model and is the same layering model defined by APPN. The following diagram shows the functional layers defined by SNA.
The lower three layers of the SNA functional layering model - Physical Control, Data Link Control, and Path Control - describe the networking services and protocols that provide the basic message forwarding infrastructure of SNA networks. These layers are collectively called the transport network.
The Physical Control and Data Link Control layers provide connections between adjacent nodes in an SNA network. The data links are LAN and WAN communications facilities that nodes use to communicate with one another. SNA generally uses industry-standard data link technologies. For wide area networking, SNA supports physical interface standards such as RS-449, RS-232, and X.2 1. The physical and data link layers defined by industry-standard LANs, such as Token-Ring, Ethernet, and FDDI are also supported.
SNA uses Synchronous Data Link Control (SDLC) protocols for communications over dedicated wide area data links. SDLC is compatible with the international standard High-Level Data Link Control (HDLC) protocol. Industry-standard packet-switching interfaces including X.25 and frame relay are also supported.
SNA also supports IBM's local channel interfaces for connecting mainframes to local nodes. Both the parallel bus and tag channel and the newer Enterprise Systems Connection (ESCON) technologies are supported by SNA.
SNA requires that its data links provide reliable message delivery. while some other types of networking protocols, such as TCP/IP, can operate over either reliable or unreliable data links, SNA always requires reliable data links. The data link protocols used in SNA networks also require that link-level acknowledgments be received within a fixed time interval - usually several seconds. This can present problems when dedicated LAN and WAN data links are replaced by networks that cannot provide fixed transit delays for messages. This situation can occur when SNA data is sent over packet-switching networks or when SNA data is tunneled through TCP/IP internets.
It should be noted that APPN's new High Performance Routing (HPR) protocol is designed to operate over unreliable data links and does not require the use of link-level error recovery protocols.
The Path Control layer is responsible for routing messages hop-to-hop across an SNA network. Subarea and APPN networks use different addressing and routing techniques, but the level of service provided to the upper layers is similar.
Within APPN networks, there are currently two different Path Control routing technologies that can be used. Intermediate Session Routing (ISR) is the original APPN routing protocol and is included in the base set of protocols which are part of every APPN product. More recently, an optional routing protocol, called High performance Routing (HPR), has been added to APPN. HPR provides better packet forwarding performance than ISR and adds capabilities such as nondisruptive session rerouting and a new flow control protocol that is optimized for operation over high bandwidth data links.
The SNA software components that support end-to-end communications are called Network Accessible Units (NAUs). The following diagram shows how NAUs fit into the SNA functional layering model. The top four layers of SNA are implemented within NAUs. These layers are the Transmission Control layer, the Data Flow Control layer, the Presentation Services layer, and the Transaction Services layer. The protocols implemented within the four layers are end-to-end protocols that are designed to support communications between a single pair of NAUs.
Subarea SNA networks contain three types of NAUs:
Each type of node in SNA networks has an architectural designation in addition to its commonly used name. VTAM Hosts are called Type 5 Nodes, Communications Controllers are Type 4 Nodes, and Peripheral Nodes are designated either Type 2.0 or Type 2.1 Nodes. Type 2.0 nodes only support hierarchical communications with mainframe-based applications while Type 2.1 Nodes also support peer-to-peer communications. The SNA node types are also commonly called PU Types - an older designation.
SNA communications is always connection oriented. All communications in SNA networks is carried out by logical connections, called sessions, between Network Accessible Units (NAUs.) NAUs are software elements that represent the end users of a SNA network as well as the network management software that resides in each node. The following diagram shows the types of NAUs that are present in SNA networks.
Logical Units (LUs) represent the end users of SNA networks. Examples of end users include applications running on VTAM Hosts or Peripheral Nodes, or the displays and printers used by interactive terminal users. End users communicate with one another via LU-LU sessions.
SNA defines several categories of LUs, called logical unit types. Each LU type defines a subset of end-to-end SNA protocols that are used to support communications between a specific category of end users. Some of the more commonly used LU types are:
System Services Control Points (SSCPs) and Physical Units (PUs) support network management functions. SSCPs are part of VTAM and always reside on SNA Hosts. SSCPs operating under the control of host-based management software, usually IBM’s NetView product, manage all of the resources of an SNA network.
Each of the managed nodes in an SNA network contains a Physical Unit (PU). PUs are responsible for the management of resources of their local nodes and they are controlled by an SSCP. SSCPs and PUs interact over SSCP-PU sessions.
Some types of LUs, called SSCP-dependent LUs, enter into sessions with their SSCPs. These SSCP-LU sessions are used to activate and deactivate LU-LU sessions between dependent LUs. Other types of LUs, called SSCP-independent LUs, can start and stop LU-LU sessions without the intervention of an SSCP. LU Type 6.2 is the only LU type that can function as an independent LU.
The design of legacy SNA networks reflects the computing and networking environment of the 1970s and 1980s. Mainframe dependency is one characteristic that can be attributed to this legacy. SNA networks are primarily designed to support hierarchical communication between end users and mainframe-based applications. Type 2.1 nodes are also capable of communicating peer-to-peer across a SNA backbone network.
Users access SNA networks primarily through dumb 3270 terminals or systems providing 3270 emulation. These devices have only one purpose - to provide interactive access to mainframe-based applications.
Another key characteristic of SNA networks is their use of fixed routes that must be preconfigured by system programmers. The administrative effort required to maintain these fixed routes is a drawback of SNA, but it gives network managers a high degree of control over level of service provided to each end user. When users initiate an LU-LU session they can specify the class of service that they require. Class of service defines the required route characteristics including bandwidth, cost, security, and availability needed to satisfy the user’s performance requirements.
The good news is that SNA provides a highly controlled, centralized networking environment. The bad news is that it lacks the flexibility needed to support today’s decentralized applications.
In response to the networking requirements of new decentralized applications, IBM designed a “new SNA”, called Advanced Peer-to-Peer Networking (APPN.) APPN has a decentralized, mainframe-independent design and supports dynamic reconfiguration of links, nodes, and routes.
| [email protected] Home | Gen2 Ventures Home |
Copyright � 1998 Gen2 Ventures
Gen2 Ventures and [email protected] are trademarks of Gen2 Ventures